<!DOCTYPE html>
<html lang="en" class="Internet-Draft">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>A File Format to Aid in Security Vulnerability Disclosure</title>
<meta content="Edwin Foudil" name="author">
<meta content="Yakov Shafranovich" name="author">
<meta content='
       When security vulnerabilities are discovered by
researchers, proper reporting channels are often lacking. As a result,
vulnerabilities may be left unreported. This document defines a machine-parsable format
("security.txt") to help organizations describe their vulnerability disclosure practices
to make it easier for researchers to report vulnerabilities. 
    ' name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="draft-foudil-securitytxt-13" name="ietf.draft">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.9.0
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.4.0
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.6.3
    pycountry 20.7.3
    pyflakes 2.2.0
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 50.3.2
    six 1.15.0
-->
<link href="draft-foudil-securitytxt.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">@import url('https://martinthomson.github.io/i-d-template/fonts.css');

html {
  --background-color: #fff;
  --text-color: #222;
  --title-color: #191919;
  --link-color: #2a6496;
  --highlight-color: #f9f9f9;
  --line-color: #eee;
  --small-font-size: 14.5px;
}
body {
  max-width: 600px;
  margin: 75px auto;
  padding: 0 5px;
  color: var(--text-color);
  background-color: var(--background-color);
  font: 16px/22px "Lora", serif;
  scroll-behavior: smooth;
}

.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  font-family: "Cabin Condensed", sans-serif;
  font-weight: 600;
  margin: 0.8em 0 0.3em;
  font-size-adjust: 0.5;
  color: var(--title-color);
}
#title {
  padding: 1em 0 0.2em;
  font-size: 32px;
  line-height: 40px;
  clear: both;
}
h1, h2, h3 {
  font-size: 22px;
  line-height: 26px;
}
h4, h5, h6 {
  font-size: 18px;
  line-height: 22px;
}

/* general structure */
.author {
  padding-bottom: 0.3em;
}
#abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
  font-size: 18px;
  line-height: 24px;
}
p {
  padding: 0;
  margin: 0.5em 0;
  text-align: left;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: var(--highlight-color);
  border: 1px solid var(--line-color);
  border-radius: 3px;
  padding: 0.5em 1em 0;
  margin-bottom: 0.5em;
}
.alignRight.art-text pre {
  padding: 0;
  width: auto;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: var(--highlight-color);
  border: 1px solid var(--line-color);
  border-radius: 3px;
  padding: 0.5em 1em 0;
  margin-bottom: 0.5em;
}
.alignCenter.art-text pre {
  padding: 0;
  width: auto;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}
dd.break {
  display: none;
}

/* links */
a, a[href].selfRef:hover {
  text-decoration: none;
}
a[href].selfRef {
  color: var(--text-color);
}
a[href] {
  color: var(--link-color);
}
a[href]:hover {
  text-decoration: underline;
}
a[href].selfRef:hover {
  background-color: var(--highlight-color);
}
a.xref {
  white-space: nowrap;
}

/* Figures */
tt, code, pre {
  background-color: var(--highlight-color);
  font: 14px/22px 'Oxygen Mono', monospace;
}
pre {
  border: 1px solid var(--line-color);
  font-size: 13.5px;
  line-height: 16px;
  letter-spacing: -0.2px;
  margin: 5px;
  padding: 5px;
}
img {
  max-width: 100%;
}
figure {
  margin: 0.5em 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption, caption {
  font-style: italic;
  margin: 0.5em 1.5em;
  text-align: left;
}
@media screen {
  pre {
    display: inline-block;
    overflow-x: auto;
    max-width: 100%;
    width: calc(100% - 22px - 1em);
  }
  figure pre {
    display: block;
    width: calc(100% - 25px);
  }
  pre + .pilcrow {
    display: inline-block;
    vertical-align: text-bottom;
    padding-bottom: 8px;
  }
  table {
    display: inline-block;
    overflow-x: auto;
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 0 2em;
  font-style: italic;
}
blockquote {
  background-color: var(--highlight-color);
  border: 1px solid var(--line-color);
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  max-width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
}
table.right {
  margin-left: auto;
}
table.center {
  margin-left: auto;
  margin-right: auto;
}
table.left {
  margin-right: auto;
}
thead, tbody {
  border: 1px solid var(--line-color);
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 5px 10px;
}
th {
  background-color: var(--line-color);
}
tr:nth-child(2n) > td {
  background-color: var(--background-color);
}
tr:nth-child(2n+1) > td {
  background-color: var(--highlight-color);
}
thead+tbody > tr:nth-child(2n) > td {
  background-color: var(--highlight-color);
}
thead+tbody > tr:nth-child(2n+1) > td {
  background-color: var(--background-color);
}
table caption {
  margin: 0;
  padding: 3px 1em;
}
table p {
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  margin-left: 3px;
  visibility: hidden;
  user-select: none;
}
a.pilcrow[href] { color: #ddd; }
a.pilcrow[href]:hover { text-decoration: none; }
@media screen {
  :hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid var(--line-color);
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: var(--small-font-size);
  line-height: 18px;
  --identifier-width: 8em;
}
#identifiers dt {
  width: var(--identifier-width);
  margin: 0;
  clear: left;
  float: left;
  text-align: right;
}
#identifiers dd {
  margin: 0 0 0 calc(1em + var(--identifier-width));
  min-width: 5em;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #999;
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
#toc nav ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
#toc nav li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
#toc a.xref {
  white-space: normal;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 500px) {
  .index ul {
    column-count: 2;
    column-gap: 20px;
  }
  .index ul ul {
    column-count: 1;
    column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}
address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}
@media (min-width: 500px) {
  #authors-addresses > section {
    column-count: 2;
    column-gap: 20px;
  }
  #authors-addresses > section > h2 {
    column-span: all;
  }
  /* hack for break-inside: avoid-column */
  #authors-addresses address {
    display: inline-block;
    break-inside: avoid-column;
  }
}

.rfcEditorRemove p:first-of-type {
  font-style: italic;
}
.cref {
  background-color: rgba(249, 232, 105, 0.3);
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 929px) {
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    border-bottom: 1px solid #ccc;
    opacity: 0.6;
  }
  #toc.active {
      opacity: 1;
  }
  #toc h2 {
    margin: 0;
    padding: 2px 0 2px 6px;
    padding-right: 1em;
    font-size: 18px;
    line-height: 24px;
    min-width: 190px;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 8px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    background-color: var(--background-color);
    padding: 0.5em 1em 1em;
    overflow: auto;
    overscroll-behavior: contain;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
  #toc.active nav {
    display: block;
  }
  /* Make the collapsed ToC header render white on gray also when it's a link */
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
  #toc a.toplink {
    margin-top: 2px;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 930px) {
  body {
    padding-right: 360px;
    padding-right: calc(min(180px + 20%, 500px));
  }
  #toc {
    position: fixed;
    bottom: 0;
    right: 0;
    right: calc(50vw - 480px);
    width: 312px;
    margin: 0;
    padding: 0;
    z-index: 1;
  }
  #toc h2 {
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 2em;
    overflow: auto;
    overscroll-behavior: contain;
    scrollbar-width: thin;
  }
  #toc nav > ul  {
    margin-bottom: 2em;
  }
  #toc ul {
    margin: 0 0 0 4px;
    font-size: var(--small-font-size);
  }
  #toc ul p, #toc ul li {
    margin: 2px 0;
    line-height: 22px;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {
    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
}

/* Changes introduced to fix issues found during implementation */

/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}

/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin: 8px 0.5em 0;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table .text-left, table .text-left {
  text-align: left;
}
table .text-center, table .text-center {
  text-align: center;
}
table .text-right, table .text-right {
  text-align: right;
}

/* Make the alternative author contact information look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 20em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Give the table caption label the same styling as the figcaption */

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  dd {
    page-break-before: avoid;
  }
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
</head>
<body>
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">security.txt</td>
<td class="right">May 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Foudil &amp; Shafranovich</td>
<td class="center">Expires 25 November 2021</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-workgroup">Workgroup:</dt>
<dd class="workgroup">Network Working Group</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-foudil-securitytxt-13</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-05-24" class="published">24 May 2021</time>
    </dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2021-11-25">25 November 2021</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">E. Foudil</div>
</div>
<div class="author">
      <div class="author-name">Y. Shafranovich</div>
<div class="org">Nightwatch Cybersecurity</div>
</div>
</dd>
</dl>
</div>
<h1 id="title">A File Format to Aid in Security Vulnerability Disclosure</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">When security vulnerabilities are discovered by
researchers, proper reporting channels are often lacking. As a result,
vulnerabilities may be left unreported. This document defines a machine-parsable format
("security.txt") to help organizations describe their vulnerability disclosure practices
to make it easier for researchers to report vulnerabilities.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF). Note that other groups may also distribute working
        documents as Internet-Drafts. The list of current Internet-Drafts is
        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-4">
        This Internet-Draft will expire on 25 November 2021.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-motivation-prior-work-and-s" class="xref">Motivation, Prior Work and Scope</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-note-to-readers" class="xref">Note to Readers</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-the-specification" class="xref">The Specification</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-comments" class="xref">Comments</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-line-separator" class="xref">Line Separator</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-digital-signature" class="xref">Digital signature</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-extensibility" class="xref">Extensibility</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-field-definitions" class="xref">Field Definitions</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.1">
                    <p id="section-toc.1-1.3.2.5.2.1.1"><a href="#section-3.5.1" class="xref">3.5.1</a>.  <a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.3.2.5.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.2">
                    <p id="section-toc.1-1.3.2.5.2.2.1"><a href="#section-3.5.2" class="xref">3.5.2</a>.  <a href="#name-canonical" class="xref">Canonical</a><a href="#section-toc.1-1.3.2.5.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.3">
                    <p id="section-toc.1-1.3.2.5.2.3.1"><a href="#section-3.5.3" class="xref">3.5.3</a>.  <a href="#name-contact" class="xref">Contact</a><a href="#section-toc.1-1.3.2.5.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.4">
                    <p id="section-toc.1-1.3.2.5.2.4.1"><a href="#section-3.5.4" class="xref">3.5.4</a>.  <a href="#name-encryption" class="xref">Encryption</a><a href="#section-toc.1-1.3.2.5.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.5">
                    <p id="section-toc.1-1.3.2.5.2.5.1"><a href="#section-3.5.5" class="xref">3.5.5</a>.  <a href="#name-expires" class="xref">Expires</a><a href="#section-toc.1-1.3.2.5.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.6">
                    <p id="section-toc.1-1.3.2.5.2.6.1"><a href="#section-3.5.6" class="xref">3.5.6</a>.  <a href="#name-hiring" class="xref">Hiring</a><a href="#section-toc.1-1.3.2.5.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.7">
                    <p id="section-toc.1-1.3.2.5.2.7.1"><a href="#section-3.5.7" class="xref">3.5.7</a>.  <a href="#name-policy" class="xref">Policy</a><a href="#section-toc.1-1.3.2.5.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.5.2.8">
                    <p id="section-toc.1-1.3.2.5.2.8.1"><a href="#section-3.5.8" class="xref">3.5.8</a>.  <a href="#name-preferred-languages" class="xref">Preferred-Languages</a><a href="#section-toc.1-1.3.2.5.2.8.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-example-of-an-unsigned-secu" class="xref">Example of an unsigned "security.txt" file</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-example-of-a-signed-securit" class="xref">Example of a signed "security.txt" file</a><a href="#section-toc.1-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-location-of-the-securitytxt" class="xref">Location of the security.txt file</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-scope-of-the-file" class="xref">Scope of the File</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-file-format-description-and" class="xref">File Format Description and ABNF Grammar</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-compromised-files-and-incid" class="xref">Compromised Files and Incident Response</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-redirects" class="xref">Redirects</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-incorrect-or-stale-informat" class="xref">Incorrect or Stale Information</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-intentionally-malformed-fil" class="xref">Intentionally Malformed Files, Resources and Reports</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-no-implied-permission-for-t" class="xref">No Implied Permission for Testing</a><a href="#section-toc.1-1.6.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-multi-user-environments" class="xref">Multi-user Environments</a><a href="#section-toc.1-1.6.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-protecting-data-in-transit" class="xref">Protecting Data in Transit</a><a href="#section-toc.1-1.6.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.6.2.8">
                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-spam-and-spurious-reports" class="xref">Spam and Spurious Reports</a><a href="#section-toc.1-1.6.2.8.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-well-known-uris-registry" class="xref">Well-Known URIs registry</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-registry-for-securitytxt-fi" class="xref">Registry for security.txt Fields</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-note-to-readers-2" class="xref">Note to Readers</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-document-history" class="xref">Document History</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-since-draft-foudil-security" class="xref">Since draft-foudil-securitytxt-00</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-since-draft-foudil-securityt" class="xref">Since draft-foudil-securitytxt-01</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-since-draft-foudil-securitytx" class="xref">Since draft-foudil-securitytxt-02</a><a href="#section-toc.1-1.11.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.4">
                <p id="section-toc.1-1.11.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-since-draft-foudil-securitytxt" class="xref">Since draft-foudil-securitytxt-03</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.5">
                <p id="section-toc.1-1.11.2.5.1"><a href="#section-b.5" class="xref">B.5</a>.  <a href="#name-since-draft-foudil-securitytxt-" class="xref">Since draft-foudil-securitytxt-04</a><a href="#section-toc.1-1.11.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.6">
                <p id="section-toc.1-1.11.2.6.1"><a href="#section-b.6" class="xref">B.6</a>.  <a href="#name-since-draft-foudil-securitytxt-0" class="xref">Since draft-foudil-securitytxt-05</a><a href="#section-toc.1-1.11.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.7">
                <p id="section-toc.1-1.11.2.7.1"><a href="#section-b.7" class="xref">B.7</a>.  <a href="#name-since-draft-foudil-securitytxt-06" class="xref">Since draft-foudil-securitytxt-06</a><a href="#section-toc.1-1.11.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.8">
                <p id="section-toc.1-1.11.2.8.1"><a href="#section-b.8" class="xref">B.8</a>.  <a href="#name-since-draft-foudil-securitytxt-07" class="xref">Since draft-foudil-securitytxt-07</a><a href="#section-toc.1-1.11.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.9">
                <p id="section-toc.1-1.11.2.9.1"><a href="#section-b.9" class="xref">B.9</a>.  <a href="#name-since-draft-foudil-securitytxt-08" class="xref">Since draft-foudil-securitytxt-08</a><a href="#section-toc.1-1.11.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.10">
                <p id="section-toc.1-1.11.2.10.1"><a href="#section-b.10" class="xref">B.10</a>. <a href="#name-since-draft-foudil-securitytxt-09" class="xref">Since draft-foudil-securitytxt-09</a><a href="#section-toc.1-1.11.2.10.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.11">
                <p id="section-toc.1-1.11.2.11.1"><a href="#section-b.11" class="xref">B.11</a>. <a href="#name-since-draft-foudil-securitytxt-1" class="xref">Since draft-foudil-securitytxt-10</a><a href="#section-toc.1-1.11.2.11.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.12">
                <p id="section-toc.1-1.11.2.12.1"><a href="#section-b.12" class="xref">B.12</a>. <a href="#name-since-draft-foudil-securitytxt-11" class="xref">Since draft-foudil-securitytxt-11</a><a href="#section-toc.1-1.11.2.12.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.11.2.13">
                <p id="section-toc.1-1.11.2.13.1"><a href="#section-b.13" class="xref">B.13</a>. <a href="#name-since-draft-foudil-securitytxt-12" class="xref">Since draft-foudil-securitytxt-12</a><a href="#section-toc.1-1.11.2.13.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<div id="motivation">
<section id="section-1.1">
        <h3 id="name-motivation-prior-work-and-s">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-motivation-prior-work-and-s" class="section-name selfRef">Motivation, Prior Work and Scope</a>
        </h3>
<p id="section-1.1-1">Many security researchers encounter situations where they are unable
to report security vulnerabilities to organizations because there are
no reporting channels to contact the owner of a particular
resource and no information available about the vulnerability disclosure practices
of such owner.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">As per section 4 of <span>[<a href="#RFC2142" class="xref">RFC2142</a>]</span>, there is an existing convention
of using the &lt;SECURITY@domain&gt; email address for communications regarding
security issues. That convention provides only a single, email-based
channel of communication per domain, and does not provide
a way for domain owners to publish information about their security disclosure
practices.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">There are also contact conventions prescribed for Internet Service Providers (ISPs)
in section 2 of <span>[<a href="#RFC3013" class="xref">RFC3013</a>]</span>, for Computer Security Incident Response Teams (CSIRTs)
in section 3.2 of <span>[<a href="#RFC2350" class="xref">RFC2350</a>]</span> and for site operators in section 5.2 of
<span>[<a href="#RFC2196" class="xref">RFC2196</a>]</span>. As per <span>[<a href="#RFC7485" class="xref">RFC7485</a>]</span>, there is also contact information provided by
Regional Internet Registries (RIRs) and domain registries for owners of IP
addresses, autonomous system numbers (ASNs), and domain names. However, none of
these tackle the issue of how security researchers can locate contact information
and vulnerability disclosure practices for organizations in order to report
vulnerabilities.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">In this document, we define a richer, machine-parsable and more extensible way
for organizations to communicate information about their security disclosure
practices and ways to contact them. Other details of vulnerability disclosure
are outside the scope of this document. Readers are encouraged to consult other
documents such as <span>[<a href="#ISO.29147.2018" class="xref">ISO.29147.2018</a>]</span> or <span>[<a href="#CERT.CVD" class="xref">CERT.CVD</a>]</span>.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">As per <span>[<a href="#CERT.CVD" class="xref">CERT.CVD</a>]</span>, "vulnerability response" refers to reports of product vulnerabilities
which is related but distinct from reports of network intrusions and compromised
websites ("incident response"). The mechanism defined in this document is intended
to be used for the former ("vulnerability response"). If implementors want
to utilize this mechanism for incident response, they should be aware of additional
security considerations discussed in <a href="#compromise" class="xref">Section 6.1</a>.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">The "security.txt" file is intended to be complementary and not as a substitute
or replacement for other public resources maintained by organizations regarding
their security disclosure practices.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-1.2">
        <h3 id="name-terminology">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all
capitals, as shown here.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">The term "researcher" corresponds
to the terms "finder" and "reporter" in <span>[<a href="#ISO.29147.2018" class="xref">ISO.29147.2018</a>]</span> and <span>[<a href="#CERT.CVD" class="xref">CERT.CVD</a>]</span>.
The term "organization" corresponds to the term "vendor"
in <span>[<a href="#ISO.29147.2018" class="xref">ISO.29147.2018</a>]</span> and <span>[<a href="#CERT.CVD" class="xref">CERT.CVD</a>]</span>.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">The term "implementors" includes all parties involved in
the vulnerability disclosure process.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="note-to-readers">
<section id="section-2">
      <h2 id="name-note-to-readers">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-note-to-readers" class="section-name selfRef">Note to Readers</a>
      </h2>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-2-1.1">
          <strong>Note to the RFC Editor:</strong>  Please remove this section prior
to publication.<a href="#section-2-1.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-2">Development of this draft takes place on Github at: https://github.com/securitytxt/security-txt<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-specification">
<section id="section-3">
      <h2 id="name-the-specification">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-the-specification" class="section-name selfRef">The Specification</a>
      </h2>
<p id="section-3-1">This document defines a text file to be placed in a known location
that provides information about vulnerability disclosure practices of a particular organization.
The format of this file is machine-parsable and MUST follow the ABNF grammar defined in
<a href="#abnf" class="xref">Section 5</a>. This file is intended to help security researchers when
disclosing security vulnerabilities.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">By convention, the file is named "security.txt". Location and scope are described
in <a href="#location" class="xref">Section 4</a>.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">This text file contains multiple fields with different values. A field contains a "name" which is the first part of a field all the way up
to the colon (for example: "Contact:") and follows the syntax defined for "field-name" in section 3.6.8
of <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>. Field names are case-insensitive (as per section 2.3 of <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>).
The "value" comes after the field name (for example: "mailto:security@example.com") and follows the syntax
defined for "unstructured" in section 3.2.5 of <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>. The file MAY also contain blank lines.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">A field MUST always consist of a name and a value
(for example: "Contact: mailto:security@example.com"). A "security.txt" file
can have an unlimited number of fields. Each field MUST appear on
its own line. Unless specified otherwise by the field definition,
multiple values MUST NOT be chained together for a single field.
Unless otherwise indicated in a definition of a particular field, a field MAY appear
multiple times.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">Implementors should be aware that some of the fields may
contain URIs using percent-encoding (as per section 2.1 of <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>).<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="comments">
<section id="section-3.1">
        <h3 id="name-comments">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-comments" class="section-name selfRef">Comments</a>
        </h3>
<p id="section-3.1-1">Any line beginning with the "#" (%x23) symbol MUST be interpreted as a comment.
The content of the comment may contain any ASCII or Unicode characters in the
%x21-7E and %x80-FFFFF ranges plus the tab (%x09) and space (%x20) characters.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Example:<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.1-3">
<pre>
# This is a comment.
</pre><a href="#section-3.1-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="line-separator">
<section id="section-3.2">
        <h3 id="name-line-separator">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-line-separator" class="section-name selfRef">Line Separator</a>
        </h3>
<p id="section-3.2-1">Every line MUST end either with a carriage return and line feed
characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).<a href="#section-3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="signature">
<section id="section-3.3">
        <h3 id="name-digital-signature">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-digital-signature" class="section-name selfRef">Digital signature</a>
        </h3>
<p id="section-3.3-1">It is RECOMMENDED that a "security.txt" file be digitally signed
using an OpenPGP cleartext signature as described in
section 7 of <span>[<a href="#RFC4880" class="xref">RFC4880</a>]</span>. When digital signatures are used, it is also
RECOMMENDED that organizations use the "Canonical" field (as per <a href="#canonical" class="xref">Section 3.5.2</a>),
thus allowing the digital signature to authenticate the location of the file.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">When it comes to verifying the key used to generate the signature, it is always
the security researcher's responsibility to make sure the key being
used is indeed one they trust.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="extensibility">
<section id="section-3.4">
        <h3 id="name-extensibility">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-extensibility" class="section-name selfRef">Extensibility</a>
        </h3>
<p id="section-3.4-1">Like many other formats and protocols, this format may need to be extended
over time to fit the ever-changing landscape of the Internet. Therefore,
extensibility is provided via an IANA registry for fields as defined
in <a href="#registry" class="xref">Section 7.2</a>. Any fields registered via that process MUST be
considered optional. To encourage extensibility and interoperability,
researchers MUST ignore any fields they do not explicitly support.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">In general, implementors should "be conservative in what you do,
be liberal in what you accept from others" (as per <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>).<a href="#section-3.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="field-definitions">
<section id="section-3.5">
        <h3 id="name-field-definitions">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-field-definitions" class="section-name selfRef">Field Definitions</a>
        </h3>
<p id="section-3.5-1">Unless otherwise stated, all fields MUST be considered optional.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<div id="acknowledgments">
<section id="section-3.5.1">
          <h4 id="name-acknowledgments">
<a href="#section-3.5.1" class="section-number selfRef">3.5.1. </a><a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
          </h4>
<p id="section-3.5.1-1">This field indicates a link to a page where security
researchers are recognized for their reports. The page being referenced
should list security researchers that reported security vulnerabilities
and collaborated to remediate them. Organizations should be careful
to limit the vulnerability information being published in order
to prevent future attacks.<a href="#section-3.5.1-1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-2">If this field indicates a web URI, then it MUST begin with "https://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.1-2" class="pilcrow">¶</a></p>
<p id="section-3.5.1-3">Example:<a href="#section-3.5.1-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.1-4">
<pre>
Acknowledgments: https://example.com/hall-of-fame.html
</pre><a href="#section-3.5.1-4" class="pilcrow">¶</a>
</div>
<p id="section-3.5.1-5">Example security acknowledgments page:<a href="#section-3.5.1-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.1-6">
<pre>
We would like to thank the following researchers:

(2017-04-15) Frank Denis - Reflected cross-site scripting
(2017-01-02) Alice Quinn  - SQL injection
(2016-12-24) John Buchner - Stored cross-site scripting
(2016-06-10) Anna Richmond - A server configuration issue
</pre><a href="#section-3.5.1-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="canonical">
<section id="section-3.5.2">
          <h4 id="name-canonical">
<a href="#section-3.5.2" class="section-number selfRef">3.5.2. </a><a href="#name-canonical" class="section-name selfRef">Canonical</a>
          </h4>
<p id="section-3.5.2-1">This field indicates the canonical URIs where the "security.txt" file is located,
which is usually something like "https://example.com/.well-known/security.txt".
If this field indicates a web URI, then it MUST begin with "https://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.2-1" class="pilcrow">¶</a></p>
<p id="section-3.5.2-2">While this field indicates that a "security.txt" retrieved from a given URI
is intended to apply to that URI, it MUST NOT be interpreted to apply to
all canonical URIs listed within the file. Researchers SHOULD use an additional
trust mechanism such as a digital signature (as per <a href="#signature" class="xref">Section 3.3</a>) to make the
determination that a particular canonical URI is applicable.<a href="#section-3.5.2-2" class="pilcrow">¶</a></p>
<p id="section-3.5.2-3">If this field appears within a "security.txt" file, and the URI used to
retrieve that file is not listed within any canonical fields,
then the contents of the file SHOULD NOT be trusted.<a href="#section-3.5.2-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.2-4">
<pre>
Canonical: https://www.example.com/.well-known/security.txt
Canonical: https://someserver.example.com/.well-known/security.txt
</pre><a href="#section-3.5.2-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="contact">
<section id="section-3.5.3">
          <h4 id="name-contact">
<a href="#section-3.5.3" class="section-number selfRef">3.5.3. </a><a href="#name-contact" class="section-name selfRef">Contact</a>
          </h4>
<p id="section-3.5.3-1">This field indicates an address that researchers
should use for reporting security
vulnerabilities such as an email address, a phone number and/or a
web page with contact information. The "Contact" field MUST
always be present in a "security.txt" file. If this field indicates a web URI,
then it MUST begin with "https://" (as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).
Security email addresses should use the conventions defined in section
4 of <span>[<a href="#RFC2142" class="xref">RFC2142</a>]</span>.<a href="#section-3.5.3-1" class="pilcrow">¶</a></p>
<p id="section-3.5.3-2">The value MUST follow the URI syntax described in section 3 of <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>.
This means that "mailto" and "tel" URI schemes must be used
when specifying email addresses and telephone numbers, as defined in <span>[<a href="#RFC6068" class="xref">RFC6068</a>]</span>
and <span>[<a href="#RFC3966" class="xref">RFC3966</a>]</span>. When the value of this field is an email address,
it is RECOMMENDED that encryption be used (as per <a href="#encryption" class="xref">Section 3.5.4</a>).<a href="#section-3.5.3-2" class="pilcrow">¶</a></p>
<p id="section-3.5.3-3">The precedence SHOULD be in listed order. The first occurrence is the preferred
method of contact. In the example below, the first email address
("security@example.com") is the preferred method of contact.<a href="#section-3.5.3-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.3-4">
<pre>
Contact: mailto:security@example.com
Contact: mailto:security%2Buri%2Bencoded@example.com
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html
</pre><a href="#section-3.5.3-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="encryption">
<section id="section-3.5.4">
          <h4 id="name-encryption">
<a href="#section-3.5.4" class="section-number selfRef">3.5.4. </a><a href="#name-encryption" class="section-name selfRef">Encryption</a>
          </h4>
<p id="section-3.5.4-1">This field indicates an encryption key that
security researchers should use for encrypted communication. Keys MUST NOT
appear in this field - instead the value of this field
MUST be a URI pointing to a location where the key can be retrieved.
If this field indicates a web URI, then it MUST begin with "https://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.4-1" class="pilcrow">¶</a></p>
<p id="section-3.5.4-2">When it comes to verifying the authenticity of the key, it is always the security
researcher's responsibility to make sure the key being specified is indeed one
they trust. Researchers must not assume that this key is
used to generate the digital signature referenced in <a href="#signature" class="xref">Section 3.3</a>.<a href="#section-3.5.4-2" class="pilcrow">¶</a></p>
<p id="section-3.5.4-3">Example of an OpenPGP key available from a web server:<a href="#section-3.5.4-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.4-4">
<pre>
Encryption: https://example.com/pgp-key.txt
</pre><a href="#section-3.5.4-4" class="pilcrow">¶</a>
</div>
<p id="section-3.5.4-5">Example of an OpenPGP key available from an OPENPGPKEY DNS record:<a href="#section-3.5.4-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.4-6">
<pre>
Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY
</pre><a href="#section-3.5.4-6" class="pilcrow">¶</a>
</div>
<p id="section-3.5.4-7">Example of an OpenPGP key being referenced by its fingerprint:<a href="#section-3.5.4-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.4-8">
<pre>
Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f
</pre><a href="#section-3.5.4-8" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="expires">
<section id="section-3.5.5">
          <h4 id="name-expires">
<a href="#section-3.5.5" class="section-number selfRef">3.5.5. </a><a href="#name-expires" class="section-name selfRef">Expires</a>
          </h4>
<p id="section-3.5.5-1">This field indicates the date and time after which the data contained in the "security.txt"
file is considered stale and should not be used (as per <a href="#stale" class="xref">Section 6.3</a>). The value of this field is formatted
according to the Internet profile of <span>[<a href="#ISO.8601" class="xref">ISO.8601</a>]</span> as defined in <span>[<a href="#RFC3339" class="xref">RFC3339</a>]</span>. It is RECOMMENDED that the value
of this field be less than a year into the future to avoid staleness.<a href="#section-3.5.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5.5-2">This field MUST always be present and MUST NOT appear more than once.<a href="#section-3.5.5-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.5-3">
<pre>
Expires: 2021-12-31T18:37:07z
</pre><a href="#section-3.5.5-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="hiring">
<section id="section-3.5.6">
          <h4 id="name-hiring">
<a href="#section-3.5.6" class="section-number selfRef">3.5.6. </a><a href="#name-hiring" class="section-name selfRef">Hiring</a>
          </h4>
<p id="section-3.5.6-1">The "Hiring" field is used for linking to the vendor's security-related job positions.
If this field indicates a web URI, then it MUST begin with "https://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.6-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.6-2">
<pre>
Hiring: https://example.com/jobs.html
</pre><a href="#section-3.5.6-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="policy">
<section id="section-3.5.7">
          <h4 id="name-policy">
<a href="#section-3.5.7" class="section-number selfRef">3.5.7. </a><a href="#name-policy" class="section-name selfRef">Policy</a>
          </h4>
<p id="section-3.5.7-1">This field indicates a link to where the vulnerability disclosure policy is located.
This can help security researchers understand
the organization's vulnerability reporting practices.
If this field indicates a web URI, then it MUST begin with "https://"
(as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).<a href="#section-3.5.7-1" class="pilcrow">¶</a></p>
<p id="section-3.5.7-2">Example:<a href="#section-3.5.7-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.7-3">
<pre>
Policy: https://example.com/disclosure-policy.html
</pre><a href="#section-3.5.7-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="preflang">
<section id="section-3.5.8">
          <h4 id="name-preferred-languages">
<a href="#section-3.5.8" class="section-number selfRef">3.5.8. </a><a href="#name-preferred-languages" class="section-name selfRef">Preferred-Languages</a>
          </h4>
<p id="section-3.5.8-1">This field can be used to indicate a set of natural languages that
are preferred when submitting security reports. This set MAY list multiple
values, separated by commas. If this field is included then at least
one value MUST be listed. The values within this set are language tags
(as defined in <span>[<a href="#RFC5646" class="xref">RFC5646</a>]</span>). If this field is absent, security researchers
may assume that English is the language to be used (as per section 4.5
of <span>[<a href="#RFC2277" class="xref">RFC2277</a>]</span>).<a href="#section-3.5.8-1" class="pilcrow">¶</a></p>
<p id="section-3.5.8-2">The order in which they appear is not an indication of priority;
the listed languages are intended to have equal priority.<a href="#section-3.5.8-2" class="pilcrow">¶</a></p>
<p id="section-3.5.8-3">This field MUST NOT appear more than once.<a href="#section-3.5.8-3" class="pilcrow">¶</a></p>
<p id="section-3.5.8-4">Example (English, Spanish and French):<a href="#section-3.5.8-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-3.5.8-5">
<pre>
Preferred-Languages: en, es, fr
</pre><a href="#section-3.5.8-5" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="example-of-an-unsigned-securitytxt-file">
<section id="section-3.6">
        <h3 id="name-example-of-an-unsigned-secu">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-example-of-an-unsigned-secu" class="section-name selfRef">Example of an unsigned "security.txt" file</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-3.6-1">
<pre>
# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z
</pre><a href="#section-3.6-1" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="example-of-a-signed-securitytxt-file">
<section id="section-3.7">
        <h3 id="name-example-of-a-signed-securit">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-example-of-a-signed-securit" class="section-name selfRef">Example of a signed "security.txt" file</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-3.7-1">
<pre>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Canonical URI
Canonical: https://example.com/.well-known/security.txt

# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2

[signature]
-----END PGP SIGNATURE-----
</pre><a href="#section-3.7-1" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="location">
<section id="section-4">
      <h2 id="name-location-of-the-securitytxt">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-location-of-the-securitytxt" class="section-name selfRef">Location of the security.txt file</a>
      </h2>
<p id="section-4-1">For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path; e.g. https://example.com/.well-known/security.txt
as per <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span> of a domain name or IP address. For legacy compatibility, a security.txt file might be placed at the top-level path
or redirect (as per section 6.4 of <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>) to the "security.txt" file under the "/.well-known/" path. If a "security.txt" file
is present in both locations, the one in the "/.well-known/" path MUST be used.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The file MUST be accessed via HTTP 1.0 or a higher version
and the file access MUST use "https" scheme (as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>).
It MUST have a Content-Type of "text/plain"
with the default charset parameter set to "utf-8" (as per section 4.1.3 of <span>[<a href="#RFC2046" class="xref">RFC2046</a>]</span>).<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">Retrieval of "security.txt" files and resources indicated within such files may result in a redirect (as per
section 6.4 of <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>). Researchers should perform additional analysis (as per <a href="#redirects" class="xref">Section 6.2</a>) to make sure these redirects
are not malicious or pointing to resources controlled by an attacker.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="scope-of-the-file">
<section id="section-4.1">
        <h3 id="name-scope-of-the-file">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-scope-of-the-file" class="section-name selfRef">Scope of the File</a>
        </h3>
<p id="section-4.1-1">A "security.txt" file MUST only apply to the domain
or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains.
A "security.txt" file MAY also apply to products and services provided by the organization publishing the file.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">As per <a href="#motivation" class="xref">Section 1.1</a>, this specification is intended for vulnerability response.
If implementors want to use this for incident response, they should be aware of additional security considerations discussed in <a href="#compromise" class="xref">Section 6.1</a>.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">Organizations SHOULD use the policy directive (as per <a href="#policy" class="xref">Section 3.5.7</a>)
to provide additional details regarding scope and details of their vulnerability disclosure process.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Some examples appear below:<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-5">
<pre>
# The following only applies to example.com.
https://example.com/.well-known/security.txt

# This only applies to subdomain.example.com.
https://subdomain.example.com/.well-known/security.txt

# This security.txt file applies to IPv4 address of 192.0.2.0.
https://192.0.2.0/.well-known/security.txt

# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
https://[2001:db8:8:4::2]/.well-known/security.txt
</pre><a href="#section-4.1-5" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="abnf">
<section id="section-5">
      <h2 id="name-file-format-description-and">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-file-format-description-and" class="section-name selfRef">File Format Description and ABNF Grammar</a>
      </h2>
<p id="section-5-1">The file format of the "security.txt" file MUST be plain text (MIME type "text/plain") as defined
in section 4.1.3 of <span>[<a href="#RFC2046" class="xref">RFC2046</a>]</span> and MUST be encoded using UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span> in Net-Unicode form <span>[<a href="#RFC5198" class="xref">RFC5198</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The format of this file MUST follow the ABNF definition below (using
the conventions defined in <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>).<a href="#section-5-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5-3">
<pre>
body             =  signed / unsigned

signed           =  sign-header unsigned sign-footer

sign-header      =  &lt; headers and line from section 7 of [RFC4880] &gt;

sign-footer      =  &lt; OpenPGP signature from section 7 of [RFC4880] &gt;

unsigned         =  *line (contact-field eol) ; one or more required
                    *line (expires-field eol) ; exactly one required
                    *line [lang-field eol] *line ; exactly one optional
                    ; order of fields within the file is not important
                    ; except that if contact-field appears more
                    ; than once the order of those indicates
                    ; priority (see Section 3.5.3)

line             =  [ (field / comment) ] eol

eol              =  *WSP [CR] LF

field            =  ; optional fields
                    ack-field /
                    can-field /
                    contact-field / ; optional repeated instances
                    encryption-field /
                    hiring-field /
                    policy-field /
                    ext-field

fs               =  ":"

comment          =  "#" *(WSP / VCHAR / %x80-FFFFF)

ack-field        =  "Acknowledgments" fs SP uri

can-field        =  "Canonical" fs SP uri

contact-field    =  "Contact" fs SP uri

expires-field    =  "Expires" fs SP date-time

encryption-field =  "Encryption" fs SP uri

hiring-field     =  "Hiring" fs SP uri

lang-field       =  "Preferred-Languages" fs SP lang-values

policy-field     =  "Policy" fs SP uri

date-time        =  &lt; imported from section 5.6 of [RFC3339] &gt;

lang-tag         =  &lt; Language-Tag from section 2.1 of [RFC5646] &gt;

lang-values      =  lang-tag *(*WSP "," *WSP lang-tag)

uri              =  &lt; URI as per section 3 of [RFC3986] &gt;

ext-field        =  field-name fs SP unstructured

field-name       =  &lt; imported from section 3.6.8 of [RFC5322] &gt;

unstructured     =  &lt; imported from section 3.2.5 of [RFC5322] &gt;
</pre><a href="#section-5-3" class="pilcrow">¶</a>
</div>
<p id="section-5-4">"ext-field" refers to extension fields, which are discussed in <a href="#extensibility" class="xref">Section 3.4</a><a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Because of the use of URIs and well-known resources, security considerations of
<span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span> and <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span> apply here, in addition to the
considerations outlined below.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="compromise">
<section id="section-6.1">
        <h3 id="name-compromised-files-and-incid">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-compromised-files-and-incid" class="section-name selfRef">Compromised Files and Incident Response</a>
        </h3>
<p id="section-6.1-1">An attacker that has compromised a website is able to compromise
the "security.txt" file as well or setup a redirect to their own site.
This can result in security reports not being received by the organization
or sent to the attacker.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">To protect against this, organizations should use the "Canonical" field to indicate the locations
of the file (as per <a href="#canonical" class="xref">Section 3.5.2</a>), digitally sign their "security.txt"
files (as per <a href="#signature" class="xref">Section 3.3</a>), and regularly monitor the file and
the referenced resources to detect tampering.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">Security researchers should validate the "security.txt" file including verifying
the digital signature and checking any available historical records before using the information
contained in the file. If the "security.txt" file looks suspicious or compromised,
it should not be used.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">While it is not recommended, implementors may choose to use the information published
within a "security.txt" file for incident response. In such cases, extreme caution
should be taken before trusting such information, since
it may have been compromised by an attacker. Researchers should use additional methods
to verify such data including out of band verification of the PGP signature, DNSSEC-based approaches, etc.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="redirects">
<section id="section-6.2">
        <h3 id="name-redirects">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-redirects" class="section-name selfRef">Redirects</a>
        </h3>
<p id="section-6.2-1">When retrieving the file and any resources referenced in the file, researchers should record
any redirects since they can lead to a different domain or IP address controlled by an attacker. Further
inspections of such redirects is recommended before using the information contained within the file.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stale">
<section id="section-6.3">
        <h3 id="name-incorrect-or-stale-informat">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-incorrect-or-stale-informat" class="section-name selfRef">Incorrect or Stale Information</a>
        </h3>
<p id="section-6.3-1">If information and resources referenced in a "security.txt" file are incorrect
or not kept up to date, this can result in security reports not being received
by the organization or sent to incorrect contacts, thus exposing possible
security issues to third parties. Not having a "security.txt" file may be preferable
to having stale information in this file. Organizations must use
the "Expires" field (see <a href="#expires" class="xref">Section 3.5.5</a>) to indicate to researchers when
the data in the file is no longer valid.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">Organizations should ensure that information in this file and any referenced
resources such as web pages, email addresses, and telephone numbers
are kept current, are accessible, controlled by the organization,
and are kept secure.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="intentionally-malformed-files-resources-and-reports">
<section id="section-6.4">
        <h3 id="name-intentionally-malformed-fil">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-intentionally-malformed-fil" class="section-name selfRef">Intentionally Malformed Files, Resources and Reports</a>
        </h3>
<p id="section-6.4-1">It is possible for compromised or malicious sites to create files that are extraordinarily
large or otherwise malformed in an attempt to discover or exploit weaknesses
in parsing code. Researchers should make sure that any such code
is robust against large or malformed files and fields, and may choose not to parse
files larger than 32 KBs, having fields longer than 2,048 characters or
containing more than 1,000 lines. The ABNF grammar (as defined in
<a href="#abnf" class="xref">Section 5</a>) can also be used as a way to verify these files.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<p id="section-6.4-2">The same concerns apply to any other resources referenced within "security.txt"
files, as well as any security reports received as a result of publishing
this file. Such resources and reports may be hostile, malformed or malicious.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="no-implied-permission-for-testing">
<section id="section-6.5">
        <h3 id="name-no-implied-permission-for-t">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-no-implied-permission-for-t" class="section-name selfRef">No Implied Permission for Testing</a>
        </h3>
<p id="section-6.5-1">The presence of a "security.txt" file might be interpreted by researchers
as providing permission to do security testing against the domain or IP address
where it is published, or products and services provided by the organization publishing
the file.
This might result in increased testing against an organization by researchers. On the other hand, a decision not
to publish a "security.txt" file might be interpreted by the
organization operating that website to be a way to signal to researchers
that permission to test that particular site or project is denied. This might result in pushback against
researchers reporting security issues to that organization.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">Therefore, researchers shouldn't assume that presence or absence of
a "security.txt" file grants or denies permission for security testing.
Any such permission may be indicated in the company's vulnerability disclosure policy
(as per <a href="#policy" class="xref">Section 3.5.7</a>) or a new field (as per <a href="#extensibility" class="xref">Section 3.4</a>).<a href="#section-6.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="multi-user-environments">
<section id="section-6.6">
        <h3 id="name-multi-user-environments">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-multi-user-environments" class="section-name selfRef">Multi-user Environments</a>
        </h3>
<p id="section-6.6-1">In multi-user / multi-tenant environments, it may possible for a user to take
over the location of the "security.txt" file. Organizations should reserve
the "security.txt" namespace at the root to ensure no third-party can create a page with
the "security.txt" AND "/.well-known/security.txt" names.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protecting-data-in-transit">
<section id="section-6.7">
        <h3 id="name-protecting-data-in-transit">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-protecting-data-in-transit" class="section-name selfRef">Protecting Data in Transit</a>
        </h3>
<p id="section-6.7-1">To protect a "security.txt" file from being tampered with in transit, implementors MUST use
HTTPS (as per section 2.7.2 of <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>) when serving the file itself and for retrieval of any web URIs
referenced in it (except when otherwise noted in this specification). As part of the TLS
handshake, researchers should validate the provided X.509 certificate
in accordance with <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span> and the following considerations:<a href="#section-6.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.7-2.1">Matching is performed only against the DNS-ID identifiers.<a href="#section-6.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.7-2.2">DNS domain names in server certificates MAY contain the wildcard
character '*' as the complete left-most label within the identifier.<a href="#section-6.7-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.7-3">The certificate may also be checked for revocation via the Online Certificate Status
Protocol (OCSP) <span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span>, certificate revocation lists (CRLs), or similar mechanisms.<a href="#section-6.7-3" class="pilcrow">¶</a></p>
<p id="section-6.7-4">In cases where the "security.txt" file cannot be served via HTTPS (such as localhost) or is
being served with an invalid certificate, additional human validation is recommended since
the contents may have been modified while in transit.<a href="#section-6.7-4" class="pilcrow">¶</a></p>
<p id="section-6.7-5">As an additional layer of protection, it is also recommended that
organizations digitally sign their "security.txt" file with OpenPGP (as per <a href="#signature" class="xref">Section 3.3</a>).
Also, to protect security reports from being tampered with or observed while in transit,
organizations should specify encryption keys (as per <a href="#encryption" class="xref">Section 3.5.4</a>) unless
HTTPS is being used for report submission.<a href="#section-6.7-5" class="pilcrow">¶</a></p>
<p id="section-6.7-6">However, the determination of validity of such keys is out of scope
for this specification. Security researchers need to establish other secure means to
verify them.<a href="#section-6.7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="spam-and-spurious-reports">
<section id="section-6.8">
        <h3 id="name-spam-and-spurious-reports">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-spam-and-spurious-reports" class="section-name selfRef">Spam and Spurious Reports</a>
        </h3>
<p id="section-6.8-1">Similar to concerns in <span>[<a href="#RFC2142" class="xref">RFC2142</a>]</span>, denial of service attacks via spam reports
would become easier once a "security.txt" file is published by
an organization. In addition, there is an increased likelihood of reports
being sent in an automated fashion and/or as result of automated scans without
human analysis. Attackers can also use this file as a way to spam unrelated
third parties by listing their resources and/or contact information.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<p id="section-6.8-2">Organizations need to weigh the advantages of publishing this file versus
the possible disadvantages and increased resources required to analyze
security reports.<a href="#section-6.8-2" class="pilcrow">¶</a></p>
<p id="section-6.8-3">Security researchers should review all information within the "security.txt"
file before submitting reports in an automated fashion or as resulting from automated scans.<a href="#section-6.8-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iana-considerations">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">Implementors should be aware that any resources referenced within
a "security.txt" file MUST NOT point to the Well-Known URIs namespace unless
they are registered with IANA (as per <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span>).<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="well-known-uris-registry">
<section id="section-7.1">
        <h3 id="name-well-known-uris-registry">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-well-known-uris-registry" class="section-name selfRef">Well-Known URIs registry</a>
        </h3>
<p id="section-7.1-1">The "Well-Known URIs" registry should be updated with the following additional
values (using the template from <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span>):<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">URI suffix: security.txt<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">Change controller: IETF<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">Specification document(s): this document<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">Status: permanent<a href="#section-7.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="registry">
<section id="section-7.2">
        <h3 id="name-registry-for-securitytxt-fi">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-registry-for-securitytxt-fi" class="section-name selfRef">Registry for security.txt Fields</a>
        </h3>
<p id="section-7.2-1">IANA is requested to create the "security.txt Fields" registry in
accordance with <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. This registry will contain fields for
use in "security.txt" files, defined by this specification.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">New registrations or updates MUST be published in accordance with the
"Expert Review" guidelines as described in sections 4.5 and 5 of
<span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. Any new field thus registered is considered optional
by this specification unless a new version of this specification is published.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">Designated Experts are expected to check whether a proposed registration or update
makes sense in the context of industry accepted vulnerability disclosure processes
such as <span>[<a href="#ISO.29147.2018" class="xref">ISO.29147.2018</a>]</span> and <span>[<a href="#CERT.CVD" class="xref">CERT.CVD</a>]</span>, and provides value to organizations
and researchers using this format.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">New registrations and updates MUST contain the following information:<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.2-5">
<li id="section-7.2-5.1">Name of the field being registered or updated<a href="#section-7.2-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.2-5.2">Short description of the field<a href="#section-7.2-5.2" class="pilcrow">¶</a>
</li>
          <li id="section-7.2-5.3">Whether the field can appear more than once<a href="#section-7.2-5.3" class="pilcrow">¶</a>
</li>
          <li id="section-7.2-5.4">The document in which the specification of the field is published (if available)<a href="#section-7.2-5.4" class="pilcrow">¶</a>
</li>
          <li id="section-7.2-5.5">
            <p id="section-7.2-5.5.1">New or updated status, which MUST be one of:<a href="#section-7.2-5.5.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2-5.5.2.1">current: The field is in current use<a href="#section-7.2-5.5.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2-5.5.2.2">deprecated: The field has been in use, but new usage is discouraged<a href="#section-7.2-5.5.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.2-5.5.2.3">historic: The field is no longer in current use<a href="#section-7.2-5.5.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-7.2-5.6">Change controller<a href="#section-7.2-5.6" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-7.2-6">An update may make a notation on an existing registration indicating
that a registered field is historical or deprecated if appropriate.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<p id="section-7.2-7">The initial registry contains these values:<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.2-8">
<pre>
   Field Name: Acknowledgments
   Description: link to page where security researchers are recognized
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Canonical
   Description: canonical URI for this file
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Contact
   Description: contact information to use for reporting vulnerabilities
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Expires
   Description: date and time after which this file is considered stale
   Multiple Appearances: No
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Encryption
   Description: link to a key to be used for encrypted communication
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Hiring
   Description: link to the vendor's security-related job positions
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Policy
   Description: link to security policy page
   Multiple Appearances: Yes
   Published in: this document
   Status: current
   Change controller: IETF

   Field Name: Preferred-Languages
   Description: list of preferred languages for security reports
   Multiple Appearances: No
   Published in: this document
   Status: current
   Change controller: IETF
</pre><a href="#section-7.2-8" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="contributors">
<section id="section-8">
      <h2 id="name-contributors">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-8-1">The authors would like to acknowledge the help provided during the
development of this document by Tom Hudson, Jobert Abma,
Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo Vela, and Krzysztof Kotowicz.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">The authors would also like to acknowledge the feedback provided by multiple members of IETF's
LAST CALL, SAAG, and SECDISPATCH lists.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Yakov would like to also thank L.T.S. (for everything).<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2046">[RFC2046]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span><span class="refAuthor"> and N. Borenstein</span>, <span class="refTitle">"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"</span>, <span class="seriesInfo">RFC 2046</span>, <span class="seriesInfo">DOI 10.17487/RFC2046</span>, <time datetime="1996-11" class="refDate">November 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2046">https://www.rfc-editor.org/info/rfc2046</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2142">[RFC2142]</dt>
        <dd>
<span class="refAuthor">Crocker, D.</span>, <span class="refTitle">"Mailbox Names for Common Services, Roles and Functions"</span>, <span class="seriesInfo">RFC 2142</span>, <span class="seriesInfo">DOI 10.17487/RFC2142</span>, <time datetime="1997-05" class="refDate">May 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2142">https://www.rfc-editor.org/info/rfc2142</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2277">[RFC2277]</dt>
        <dd>
<span class="refAuthor">Alvestrand, H.</span>, <span class="refTitle">"IETF Policy on Character Sets and Languages"</span>, <span class="seriesInfo">BCP 18</span>, <span class="seriesInfo">RFC 2277</span>, <span class="seriesInfo">DOI 10.17487/RFC2277</span>, <time datetime="1998-01" class="refDate">January 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2277">https://www.rfc-editor.org/info/rfc2277</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3339">[RFC3339]</dt>
        <dd>
<span class="refAuthor">Klyne, G.</span><span class="refAuthor"> and C. Newman</span>, <span class="refTitle">"Date and Time on the Internet: Timestamps"</span>, <span class="seriesInfo">RFC 3339</span>, <span class="seriesInfo">DOI 10.17487/RFC3339</span>, <time datetime="2002-07" class="refDate">July 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3339">https://www.rfc-editor.org/info/rfc3339</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3629">[RFC3629]</dt>
        <dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3966">[RFC3966]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refTitle">"The tel URI for Telephone Numbers"</span>, <span class="seriesInfo">RFC 3966</span>, <span class="seriesInfo">DOI 10.17487/RFC3966</span>, <time datetime="2004-12" class="refDate">December 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3966">https://www.rfc-editor.org/info/rfc3966</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span><span class="refAuthor">, Fielding, R.</span><span class="refAuthor">, and L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4880">[RFC4880]</dt>
        <dd>
<span class="refAuthor">Callas, J.</span><span class="refAuthor">, Donnerhacke, L.</span><span class="refAuthor">, Finney, H.</span><span class="refAuthor">, Shaw, D.</span><span class="refAuthor">, and R. Thayer</span>, <span class="refTitle">"OpenPGP Message Format"</span>, <span class="seriesInfo">RFC 4880</span>, <span class="seriesInfo">DOI 10.17487/RFC4880</span>, <time datetime="2007-11" class="refDate">November 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4880">https://www.rfc-editor.org/info/rfc4880</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5198">[RFC5198]</dt>
        <dd>
<span class="refAuthor">Klensin, J.</span><span class="refAuthor"> and M. Padlipsky</span>, <span class="refTitle">"Unicode Format for Network Interchange"</span>, <span class="seriesInfo">RFC 5198</span>, <span class="seriesInfo">DOI 10.17487/RFC5198</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5198">https://www.rfc-editor.org/info/rfc5198</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5322">[RFC5322]</dt>
        <dd>
<span class="refAuthor">Resnick, P., Ed.</span>, <span class="refTitle">"Internet Message Format"</span>, <span class="seriesInfo">RFC 5322</span>, <span class="seriesInfo">DOI 10.17487/RFC5322</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5322">https://www.rfc-editor.org/info/rfc5322</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5646">[RFC5646]</dt>
        <dd>
<span class="refAuthor">Phillips, A., Ed.</span><span class="refAuthor"> and M. Davis, Ed.</span>, <span class="refTitle">"Tags for Identifying Languages"</span>, <span class="seriesInfo">BCP 47</span>, <span class="seriesInfo">RFC 5646</span>, <span class="seriesInfo">DOI 10.17487/RFC5646</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5646">https://www.rfc-editor.org/info/rfc5646</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6068">[RFC6068]</dt>
        <dd>
<span class="refAuthor">Duerst, M.</span><span class="refAuthor">, Masinter, L.</span><span class="refAuthor">, and J. Zawinski</span>, <span class="refTitle">"The 'mailto' URI Scheme"</span>, <span class="seriesInfo">RFC 6068</span>, <span class="seriesInfo">DOI 10.17487/RFC6068</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6068">https://www.rfc-editor.org/info/rfc6068</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6960">[RFC6960]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span><span class="refAuthor">, Myers, M.</span><span class="refAuthor">, Ankney, R.</span><span class="refAuthor">, Malpani, A.</span><span class="refAuthor">, Galperin, S.</span><span class="refAuthor">, and C. Adams</span>, <span class="refTitle">"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"</span>, <span class="seriesInfo">RFC 6960</span>, <span class="seriesInfo">DOI 10.17487/RFC6960</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6960">https://www.rfc-editor.org/info/rfc6960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8615">[RFC8615]</dt>
      <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"Well-Known Uniform Resource Identifiers (URIs)"</span>, <span class="seriesInfo">RFC 8615</span>, <span class="seriesInfo">DOI 10.17487/RFC8615</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8615">https://www.rfc-editor.org/info/rfc8615</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CERT.CVD">[CERT.CVD]</dt>
        <dd>
<span class="refAuthor">Software Engineering Institute, Carnegie Mellon University</span>, <span class="refTitle">"The CERT Guide to Coordinated Vulnerability Disclosure (CMU/SEI-2017-SR-022)"</span>, <time datetime="2017" class="refDate">2017</time>. </dd>
<dd class="break"></dd>
<dt id="ISO.29147.2018">[ISO.29147.2018]</dt>
        <dd>
<span class="refAuthor">International Organization for Standardization (ISO)</span>, <span class="refTitle">"ISO/IEC 29147:2018, Information technology - Security techniques - Vulnerability disclosure"</span>, <time datetime="2018" class="refDate">2018</time>. </dd>
<dd class="break"></dd>
<dt id="ISO.8601">[ISO.8601]</dt>
        <dd>
<span class="refAuthor">International Organization for Standardization (ISO)</span>, <span class="refTitle">"ISO/IEC 8601, Date and time - Representations for information interchange - Parts 1 and 2"</span>, <time datetime="2019" class="refDate">2019</time>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2196">[RFC2196]</dt>
        <dd>
<span class="refAuthor">Fraser, B.</span>, <span class="refTitle">"Site Security Handbook"</span>, <span class="seriesInfo">FYI 8</span>, <span class="seriesInfo">RFC 2196</span>, <span class="seriesInfo">DOI 10.17487/RFC2196</span>, <time datetime="1997-09" class="refDate">September 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2196">https://www.rfc-editor.org/info/rfc2196</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2350">[RFC2350]</dt>
        <dd>
<span class="refAuthor">Brownlee, N.</span><span class="refAuthor"> and E. Guttman</span>, <span class="refTitle">"Expectations for Computer Security Incident Response"</span>, <span class="seriesInfo">BCP 21</span>, <span class="seriesInfo">RFC 2350</span>, <span class="seriesInfo">DOI 10.17487/RFC2350</span>, <time datetime="1998-06" class="refDate">June 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2350">https://www.rfc-editor.org/info/rfc2350</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3013">[RFC3013]</dt>
        <dd>
<span class="refAuthor">Killalea, T.</span>, <span class="refTitle">"Recommended Internet Service Provider Security Services and Procedures"</span>, <span class="seriesInfo">BCP 46</span>, <span class="seriesInfo">RFC 3013</span>, <span class="seriesInfo">DOI 10.17487/RFC3013</span>, <time datetime="2000-11" class="refDate">November 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3013">https://www.rfc-editor.org/info/rfc3013</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7485">[RFC7485]</dt>
        <dd>
<span class="refAuthor">Zhou, L.</span><span class="refAuthor">, Kong, N.</span><span class="refAuthor">, Shen, S.</span><span class="refAuthor">, Sheng, S.</span><span class="refAuthor">, and A. Servin</span>, <span class="refTitle">"Inventory and Analysis of WHOIS Registration Objects"</span>, <span class="seriesInfo">RFC 7485</span>, <span class="seriesInfo">DOI 10.17487/RFC7485</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7485">https://www.rfc-editor.org/info/rfc7485</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
      <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="note-to-readers-1">
<section id="section-appendix.a">
      <h2 id="name-note-to-readers-2">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-note-to-readers-2" class="section-name selfRef">Note to Readers</a>
      </h2>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-appendix.a-1.1">
          <strong>Note to the RFC Editor:</strong>  Please remove this section prior
to publication.<a href="#section-appendix.a-1.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.a-2">Development of this draft takes place on Github at https://github.com/securitytxt/security-txt<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="document-history">
<section id="section-appendix.b">
      <h2 id="name-document-history">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-document-history" class="section-name selfRef">Document History</a>
      </h2>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-appendix.b-1.1">
          <strong>Note to the RFC Editor:</strong>  Please remove this section prior
to publication.<a href="#section-appendix.b-1.1" class="pilcrow">¶</a>
</li>
      </ul>
<div id="since-draft-foudil-securitytxt-00">
<section id="section-b.1">
        <h2 id="name-since-draft-foudil-security">
<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-since-draft-foudil-security" class="section-name selfRef">Since draft-foudil-securitytxt-00</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.1-1.1">Moved to use IETF's markdown tools for draft updates<a href="#section-b.1-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.2">Added table of contents and a fuller list of references<a href="#section-b.1-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.3">Moved file to .well-known URI and added IANA registration (#3)<a href="#section-b.1-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.4">Added extensibility with an IANA registry for fields (#34)<a href="#section-b.1-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.5">Added text explaining relationship to RFC 2142 / security@ email address (#25)<a href="#section-b.1-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.6">Scope expanded to include internal hosts, domains, IP addresses and file systems<a href="#section-b.1-1.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.1-1.7">Support for digital signatures added (#19)<a href="#section-b.1-1.7" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-b.1-2">The full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt-01<a href="#section-b.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="since-draft-foudil-securitytxt-01">
<section id="section-b.2">
        <h2 id="name-since-draft-foudil-securityt">
<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-since-draft-foudil-securityt" class="section-name selfRef">Since draft-foudil-securitytxt-01</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.2-1.1">Added appendix with pointer to Github and document history<a href="#section-b.2-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.2-1.2">Added external signature file to the well known URI registry (#59)<a href="#section-b.2-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.2-1.3">Added policy field (#53)<a href="#section-b.2-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.2-1.4">Added diagram explaining the location of the file on public vs. internal systems<a href="#section-b.2-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.2-1.5">Added recommendation that external signature files should use HTTPS (#55)<a href="#section-b.2-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.2-1.6">Added recommendation that organizations should monitor their security.txt files (#14)<a href="#section-b.2-1.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-b.2-2">The full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt-02<a href="#section-b.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="since-draft-foudil-securitytxt-02">
<section id="section-b.3">
        <h2 id="name-since-draft-foudil-securitytx">
<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-since-draft-foudil-securitytx" class="section-name selfRef">Since draft-foudil-securitytxt-02</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.3-1.1">Use "mailto" and "tel" (#62)<a href="#section-b.3-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.2">Fix typo in the "Example" section (#64)<a href="#section-b.3-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.3">Clarified that the root directory is a fallback option (#72)<a href="#section-b.3-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.4">Defined content-type for the response (#68)<a href="#section-b.3-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.5">Clarify the scope of the security.txt file (#69)<a href="#section-b.3-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.6">Cleaning up text based on the NITS tools suggestions (#82)<a href="#section-b.3-1.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.7">Added clarification for newline values<a href="#section-b.3-1.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.8">Clarified the encryption field language, added examples
of DNS-stored encryption keys (#28 and #94)<a href="#section-b.3-1.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.3-1.9">Added "Hiring" field<a href="#section-b.3-1.9" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-03">
<section id="section-b.4">
        <h2 id="name-since-draft-foudil-securitytxt">
<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-since-draft-foudil-securitytxt" class="section-name selfRef">Since draft-foudil-securitytxt-03</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.4-1.1">Added "Hiring" field to the registry section<a href="#section-b.4-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.2">Added an encryption example using a PGP fingerprint (#107)<a href="#section-b.4-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.3">Added reference to the mailing list (#111)<a href="#section-b.4-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.4">Added a section referencing related work (#113)<a href="#section-b.4-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.5">Fixes for idnits (#82)<a href="#section-b.4-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.6">Changing some references to informative instead of normative<a href="#section-b.4-1.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.7">Adding "Permission" field (#30)<a href="#section-b.4-1.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.8">Fixing remaining ABNF issues (#83)<a href="#section-b.4-1.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.4-1.9">Additional editorial changes and edits<a href="#section-b.4-1.9" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-04">
<section id="section-b.5">
        <h2 id="name-since-draft-foudil-securitytxt-">
<a href="#section-b.5" class="section-number selfRef">B.5. </a><a href="#name-since-draft-foudil-securitytxt-" class="section-name selfRef">Since draft-foudil-securitytxt-04</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.5-1.1">Addressing IETF feedback (#118)<a href="#section-b.5-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.2">Case sensitivity clarification (#127)<a href="#section-b.5-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.3">Syntax fixes (#133, #135 and #136)<a href="#section-b.5-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.4">Removed permission field (#30)<a href="#section-b.5-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.5">Removed signature field and switched to inline signatures (#93 and #128)<a href="#section-b.5-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.6">Adding canonical field (#100)<a href="#section-b.5-1.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.7">Text and ABNF grammar improvements plus ABNF changes for comments (#123)<a href="#section-b.5-1.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.5-1.8">Changed ".security.txt" to "security.txt" to be consistent<a href="#section-b.5-1.8" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-05">
<section id="section-b.6">
        <h2 id="name-since-draft-foudil-securitytxt-0">
<a href="#section-b.6" class="section-number selfRef">B.6. </a><a href="#name-since-draft-foudil-securitytxt-0" class="section-name selfRef">Since draft-foudil-securitytxt-05</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.6-1.1">Changing HTTPS to MUST (#55)<a href="#section-b.6-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.6-1.2">Adding language recommending encryption for email reports (#134)<a href="#section-b.6-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.6-1.3">Added language handling redirects (#143)<a href="#section-b.6-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.6-1.4">Expanded security considerations section and fixed typos (#30, #73, #103, #112)<a href="#section-b.6-1.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-06">
<section id="section-b.7">
        <h2 id="name-since-draft-foudil-securitytxt-06">
<a href="#section-b.7" class="section-number selfRef">B.7. </a><a href="#name-since-draft-foudil-securitytxt-06" class="section-name selfRef">Since draft-foudil-securitytxt-06</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.7-1.1">Fixed ABNF grammar for non-chainable fields (#150)<a href="#section-b.7-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.7-1.2">Clarified ABNF grammar (#152)<a href="#section-b.7-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.7-1.3">Clarified redirect logic (#143)<a href="#section-b.7-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.7-1.4">Clarified comments (#158)<a href="#section-b.7-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.7-1.5">Updated references and template for well-known URI to RFC 8615<a href="#section-b.7-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.7-1.6">Fixed nits from the IETF validator<a href="#section-b.7-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-07">
<section id="section-b.8">
        <h2 id="name-since-draft-foudil-securitytxt-07">
<a href="#section-b.8" class="section-number selfRef">B.8. </a><a href="#name-since-draft-foudil-securitytxt-07" class="section-name selfRef">Since draft-foudil-securitytxt-07</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.8-1.1">Addressing AD feedback (#165)<a href="#section-b.8-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.8-1.2">Fix for ABNF grammar in lang-values (#164)<a href="#section-b.8-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.8-1.3">Fixing idnits warnings<a href="#section-b.8-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.8-1.4">Adding guidance for designated experts<a href="#section-b.8-1.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-08">
<section id="section-b.9">
        <h2 id="name-since-draft-foudil-securitytxt-08">
<a href="#section-b.9" class="section-number selfRef">B.9. </a><a href="#name-since-draft-foudil-securitytxt-08" class="section-name selfRef">Since draft-foudil-securitytxt-08</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.9-1.1">Added language and example regarding URI encoding (#176)<a href="#section-b.9-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.9-1.2">Add "Expires" field (#181)<a href="#section-b.9-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.9-1.3">Changed language from "directive" to "field" (#182)<a href="#section-b.9-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.9-1.4">Addressing last call feedback (#179, #180 and #183)<a href="#section-b.9-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.9-1.5">Clarifying order of fields (#174)<a href="#section-b.9-1.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.9-1.6">Revert comment/field association (#158)<a href="#section-b.9-1.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-09">
<section id="section-b.10">
        <h2 id="name-since-draft-foudil-securitytxt-09">
<a href="#section-b.10" class="section-number selfRef">B.10. </a><a href="#name-since-draft-foudil-securitytxt-09" class="section-name selfRef">Since draft-foudil-securitytxt-09</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.10-1.1">Adjust ABNF to allow blank lines between directives (#191)<a href="#section-b.10-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.10-1.2">Make "Expires" field required (#190)<a href="#section-b.10-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.10-1.3">Adding a warning about the well-known URI namespace (#188)<a href="#section-b.10-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.10-1.4">Adding scope language around products/services (#185)<a href="#section-b.10-1.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.10-1.5">Addressing last call feedback (#189)<a href="#section-b.10-1.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-10">
<section id="section-b.11">
        <h2 id="name-since-draft-foudil-securitytxt-1">
<a href="#section-b.11" class="section-number selfRef">B.11. </a><a href="#name-since-draft-foudil-securitytxt-1" class="section-name selfRef">Since draft-foudil-securitytxt-10</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.11-1.1">Changes addressing IESG feedback<a href="#section-b.11-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.11-1.2">Removed language regarding file systems (#201)<a href="#section-b.11-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.11-1.3">Adding language to explain alignment with the CERT CVD guide (#202)<a href="#section-b.11-1.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-11">
<section id="section-b.12">
        <h2 id="name-since-draft-foudil-securitytxt-11">
<a href="#section-b.12" class="section-number selfRef">B.12. </a><a href="#name-since-draft-foudil-securitytxt-11" class="section-name selfRef">Since draft-foudil-securitytxt-11</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.12-1.1">Changed date format from RFC 5322 to RFC 3339 / ISO 8601 (#208)<a href="#section-b.12-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.12-1.2">Added clarification in "canonical" field regarding the URI used to retrieve the file<a href="#section-b.12-1.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.12-1.3">Added language about machine-parsability<a href="#section-b.12-1.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-b.12-1.4">Added quotes around "security.txt" for consistency<a href="#section-b.12-1.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="since-draft-foudil-securitytxt-12">
<section id="section-b.13">
        <h2 id="name-since-draft-foudil-securitytxt-12">
<a href="#section-b.13" class="section-number selfRef">B.13. </a><a href="#name-since-draft-foudil-securitytxt-12" class="section-name selfRef">Since draft-foudil-securitytxt-12</a>
        </h2>
<ul class="normal">
<li class="normal" id="section-b.13-1.1">TBD<a href="#section-b.13-1.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-b.13-2">Full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt<a href="#section-b.13-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Edwin Foudil</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:contact@edoverflow.com" class="email">contact@edoverflow.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yakov Shafranovich</span></div>
<div dir="auto" class="left"><span class="org">Nightwatch Cybersecurity</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yakov+ietf@nightwatchcybersecurity.com" class="email">yakov+ietf@nightwatchcybersecurity.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>
